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POLICY-BASED NETWORK MANAGEMENT lar embodiment, a computer-implemented method for man- 

SYSTEM USING DYNAMIC POLICY aging a network includes evaluating a condition relating to 

GENERATION a network resource, generating instructions for managing 

access to the network resource in response to the evaluation, 

FIELD OF THE INVENTION 5 and insulting the instructions on a network device providing 

The present invention relates generally to the field of acccss to ^ nctwork rcsourcc - 

computer networking, and in particular to an improved BRIEF DESCRIPTION OF THE DRAWINGS 
pohcy-based network management system. 

BACKGROUND OF THE INVENTION ^ IG * 1 is a block diagram of a PBNM architecture of a 

, 10 type in which embodiments of the present invention may be 

A computer network, such as a corporate intranet, a local implemented 
area network (LAN), or a wide area network (WAN), can be 

viewed as a collection of network resources. Network FIG * 2 15 a block of a P ohc y **™ for use m 

resources might include, for example, database servers, accordance with the PBNM architecture of FIG. 1. 

hosts, switches, routers, and firewalls. Since there are typi- 15 FIG. 3 is a diagram of a tree-based approach to policy 

cally many different users competing for access to the same specification for use in accordance with the PBNM archi- 

network resources, it is desirable to have some form of lecture of FIG. 1. 

network management facility. FIG. 4 is an example of a particular implementation of the 

In the current state of the art, console-based management tree-based approach to policy specification shown in FIG, 3. 

is the most common approach to network management. In 20 piG. 5 is a block diagram illustrating a data structure for 

console-based management, one or more console operators use m dynamic policy generation in accordance with an 

(typically members of an information technology group or embodiment of the present invention, 

similar organization within an enterprise) manually config- FIG. 6 is a flow diagram for dynamic policy processing in 

ure each resource on the network to implement the enter- accordance ^ an embodiment of the present invention 

pnse's policies for network use. However, console-based 25 usi ^ data stfUCture illustrated m FIG ^ 5 . 
management is labor intensive, and is typically slow to 

respond to changing network conditions. DETAILED DESCRIPTION 

Recently, a new technology called policy-based network _ ... „ 

management (PBNM) has emerged. PBNM allows policies ^ P reseDt invention relates generally to an improved 

relating to the use of network resources to be stored in a 30 policy-based network management system. Policy-based 

management system for use in a more automated fashion ° etvvc * k management is a relatively-recent advance in the 

than is generally possible with console-based management. fi L eld of management, responding in part to dramatic 

From an architectural standpoint, a PBNM system lhal , hav < ' takeD P la f m ^ ™? * e In ' e ™ e ! and 

• i j i . . c n i a A corporate networks (e.g., intranets) are used. PBNM has 

includes several different types of entities. Policy decision . . ^ L \ , . e . „. 

■ . /nrxTi \ , i • • * r * it proven to be a valuable mechanism for controlling access to 
pouits (PDPs) store policies, examine requests for access to 35 y t . - t . -ui * . 
r „ , J -jc v # network resources, for promoting responsible use of net- 
network resources received from pohcy enforcement points - . - i . * . . 

/ncD \ j . ♦ # r • t L < u„.„ work bandwidth, multicast groups, security and encryption, 
(PEPs), and compare such requests to any policies that have , . ' j * i 
u „* ur u a c~ *t » tp ™„k 0[ . tft ki,vt, Q ^ and other such resources, and for enabhng centralized con- 
been established for those resources. If such established A . r . , , A , L A • ' . b 

i* * ■ * nnn j -j *u ■ * / trol of widely -distributed devices, 

pohcies exist, PDPs decide on the appropriate action (e.g., . ' 

approve or deny an access request) and accordingly inform «o 0ne existing approach to policy-based network manage- 

one or more policy enforcement points (PEPs). Policy ment a PP lies a client-server paradigm, and assumes that 

enforcement points are responsible for enforcing the policy individual network devices outsource policy decisions to 

decision management devices, called policy servers. Under this 

A potential shortcoming of current PBNM technology mo f [ > onc ?f. mo , re P oHc y scrvers ar f c ^sponsible for 

relates to limitations on the flexibility of the management ^ established pohcies to requests for use of network 

system. One approach to providing flexibility for policy- ^sources. Network devices, such as routers and switches, 

based network management has been to specify in advance * ct a * ^ chents > ^ S ° n the P 01 "* server for pohcy- 

all possible policies relating to each managed resource. based adm^sion control. For example, when a router 

However, such an approach requires substantial administra- receives a request to join an IP (Internet Protocol) multicast 

tor time to establish the pohcies; consumes large amounts of 50 group, the router would communicate with a predetermined 

storage space on policy servers and PDPs, since each policy ^ s u Crver 10 f er * the request can be accepted 

related to a policy enforcement point must be maintained; under tne currently-established policies, 

and consumes significant processing time because policy FIG - 1 illustrates in general fashion one possible lmple- 

servers and PDPs must evaluate potentially large numbers of mentation of a PBNM architecture to which embodiments of 

policies each time a request for a network resource is 5S the present mvention may be directed. The illustrated archi- 

received. Another approach has been to configure policies tecture assumes a single control domain 10 for network 

with "wildcards," wherein a policy includes one or more management purposes. Control domain 10 may be, for 

variables that may be satisfied by a number of different example, a Windows NT domain or a routing administrative 

values or conditions. While this latter approach helps reduce domain With i° control domain 10, a policy console 14 

system administrator time and storage requirements, sub- 60 15 uscd t0 configure, administer, and monitor pohcies and 

stantial processing time is still required to evaluate poten- their m mis example, pohcy console 14 comprises a 

tially large numbers of pohcies and to resolve any wildcard plug-in module installed in an existing network management 

references included therein. console 12, such as the OpenView management console 

available from Hewlett-Packard or the Hvoli Netview man- 

SUMMARY OF THE INVENTION 65 agemen t console available from IBM. Policy console 14 

The present invention relates to an improved policy-based may also be accessible through a Web-based management 

network management system. In accordance with a partial- tool 16, such as an appropriately ^configured browser. 
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Control domain 10 includes a policy server 18 accessible 
through policy console 14. While only a single policy server 
18 is illustrated, it is possible to incorporate a plurality of 
policy servers in any given control domain. Policy server 18 
is configured to implement policies relating to the manage- 
ment of a group of network devices within control domain 
10. To this end, policy server 18 maintains a policy database 
20 containing policy specification information for estab- 
lished policies. Policy server 18 may also maintain a log (not 
shown) of its own activity, which log can be used to, for 
example, supply accounting information for billing and 
further tuning of resource control policies. Policy console 14 
is configured to enable viewing, configuration, and modifi- 
cation of policy database 20, as well as to enable monitoring 
of activities at policy server 18. Although policy database 20 
is shown as part of policy server 18, it need not be physically 
resident on policy server 18. 

Policy server 18 is capable of communicating with a 
plurality of policy clients 22. Each policy client 22 serves as 
a policy enforcement point for policy-based control over the 
use of network resources. For instance, a request for use of 
a network resource may arrive at policy client 22, which 
must then apply active policies to determine whether or not 
to admit such a request. In the PBNM architecture shown in 
FIG. 1, policy client 22 is configured to outsource such 
decisions to policy server 18. Based on the response from 
policy server 18, policy client 22 enforces the decision by 
either allowing or disallowing the request. 

Policy client 22 typically resides at a network device 
responsible for data forwarding, such as a LAN switch, a 
router, or a firewall. In the PBNM architecture shown in 
FIG. 1, policy client 22 can be configured with a relatively- 
simple structure because it oif -loads policy-interpretation 
tasks to policy server 18. For example, when policy client 22 
receives a request for access to a resource under its control, 
it simply sends a query to policy server 18 using an 
appropriate protocol (an example of which is described 
below). Policy server 18 determines whether to allow the 
access, and communicates the decision to policy client 22. 
Policy client 22 may also cache responses from policy server 
18 for future use. 

In the arrangement shown in FIG. 1, policy server 18 is 
responsible for the majority of the policy-related 
functionality, and is capable of managing a plurality of 
clients with potentially-diverse policy criteria. To support 
this type of flexibility, as well as to permit extensibility, 
policy-server 18 applies an object-based representation and 
exchange of information. 

As is generally known in the art, policy server 18 com- 
prises four major components, as shown in FIG. 2. Policy 
client communication module 40 is responsible for handling 
communications with the various policy clients 22 in com- 
munication with policy server 18. Pre/postprocessing mod- 
ule 42 is responsible for preprocessing, interpretation and 
postprocessing of wire-format objects for use within the 
internal policy structures. Core processing logic module 44 
provides the core logic for policy server 18, and includes the 
policy structures and processing for their application. 
Finally, console communication module 46 handles com- 
munication with policy console 14 (and/or Web-based man- 
agement tool 16). Core processing logic module 44 also 
handles authentication (with the aid of a possibly-remote 
authentication server (not shown)) and logging of all rel- 
evant information into a common SNMP (Simple Network 
Management Protocol) MIB (Management Information 
Base) that can then be used for purposes of, for example, 
accounting, monitoring, and billing. SNMP is a means for 
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remotely accessing information about the status and con- 
figuration of network devices, while an MIB is used to 
define structure and syntax for information that is specific to 
a particular set of functionality provided by a device. Thus, 

s for example, a system administrator might use SNMP to 
access an MIB that contains logging information about 
policy decisions made by a PDP. 

Policies are often configured in a manner that facilitates 
automated parsing. For example, a policy relating to use of 

10 bandwidth on a particular network segment might be con- 
figured as follows: 

Allow User_X to use up to 1 Mbit/s of bandwidth on Subnet_Y 
between 8 AM and 5 PM. 

15 This policy would then be used by the network management 
system to dynamically determine whether to grant a request 
by User_X for access to Subnet_Y. 

Policies can also be implemented with "wildcards" to 

^ provide increased flexibility. For example, the above policy 
could be more generally expressed as: 

Allow User_X to use up to 1 Mbit/s of bandwidth on ANYSUB- 
NET between 8 AM and 5 PM, 

25 where "ANYSUBNET" is a variable that permits the con- 
dition to be satisfied by a request for access to any subnet, 
including but not limited to Subnet_Y. Implementation of 
such wildcards is widespread in PBNM systems, as they are 
useful for authoring policies where the conditions that will 

30 be present at the time the policy is enforced are not fully 
known ahead of time. 

To illustrate the operation of the PBNM system shown in 
FIG. 1, consider a set of policies designed to restrict the use 
of network bandwidth on a corporate intranet. In this 

35 arrangement, an application desiring access to a network 
resource, such as a corporate database, can use a protocol 
such as RSVP (Resource ReSerVation Protocol), to request 
reservation of bandwidth for a data stream, and the request 
propagates from the application through the network 

40 towards the source of the desired data stream (i.e., the 
database server). The request must be accepted by each 
intermediate device on this path, such as routers and subnet 
bandwidth managers (SBMs), In a typical non-PBNM LAN 
configuration, an SBM is responsible for accepting or deny- 

45 ing a bandwidth reservation request, whereas a router is 
responsible for reservation on its point-to-point links. A 
router or an SBM uses locally-maintained state information 
to determine whether or not there is sufficient bandwidth 
available to admit the request. However, in a PBNM system 

50 the SBM or the router must also take into account any 
established policy restrictions (e.g., restrictions on who can 
reserve bandwidth depending on factors such as requester 
identity, time of day, identity of the source or sink of the 
traffic, etc.) before accepting the request. 

55 Thus, referring again to FIG. 1, in such a case the SBM 
or router (i.e., a policy client 22) sends a query with relevant 
information to policy server 18. Policy server 18 uses 
information stored in policy database 20 and current state 
information (e.g., state of any already-admitted requests) to 

60 determine whether to accept the request, and then sends a 
response to policy client 22. Policy client 22 then either 
admits or denies the request as appropriate. In such an 
arrangement, policy server 18 comprises a policy decision 
point and policy client 22 comprises a policy enforcement 

65 point. 

Communication of policy information between policy 
server 18 and policy client 22 can be accomplished, for 
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example, using a simple request- response protocol based on protocol to query policy server 18 as to whether a reserva- 

TCP (Transfer Communications Protocol) for reliable tion request can be accepted. In its query, policy client 22 

exchange of messages. To facilitate such interactions includes objects that describe the bandwidth requirements 

between policy client 22 and policy server 18, policy client and the requesting user's identity. In its response, policy 

22 may include a local policy module (LPM) (not shown) s server 18 accepts the request at a particular priority level 

that communicates with policy server 18 for policy deci- (e.g., level 5) and also provides a policy object to be 

sions. In the arrangement of FIG. 1, for example, the LPM mcluded when the reservation request is forwarded atong the 

would initially establish a TCP connection to policy server P ath to sender * a P enod of Ume > cUem J 22 

18, and then use that connection to send queries or requests »«» a request to delete the reservation, and also provides 

to policy server 18, and to receive responses from policy 10 start and ^ me for the «saon so that pohcy server 

server 18. Communication between the LPM and policy 18 can ™* me information for accounting and billing 

server 18 is mainly in the form of request-response Purposes. This exchange is illustrated below, 

exchanges, although pohcy server 18 can also send unso- Chent->Server: RQ 

licited messages to pohcy client 22 to, for example, force a "RIH-4, client type-RSVP, RSVP objects incl. Pohcy 

change to a previously-approved state. 15 data' 

In accordance with particular implementations, responses {client sends query asking whether reservation can be 

from policy server 18 to policy client 22 may be in the form accepted} 

of an Accept with Priority. For example, a response from Server->Client: RR 

policy server 18 may include a non-negative integer indi- "RIH-4, Priority-5, OUT-POLICY object" 

eating a relative priority of the response: higher numbers 20 {server accepts request (at priority 5) and provides 

indicating higher priority, and the value zero being used to pohcy object to be forwarded to next device in path} 

completely deny a request. Such a priority value allows the Client->Server: DRQ 

LPM to sort previously-accepted requests against new "RIH=4, Reason Code«TEAR, Start Timestamp, End 

requests and make a local decision (i.e., without further Timestamp" 

intervention by policy server 18) on whether to remove 25 {client requests deletion of request and provides dura- 
previously- accepted requests. For example, assume that a tion of session information} 
router has accepted two bandwidth reservations with priori- A significant component of any PBNM architecture is the 
ties 2 and 5 to take up 800 Kbps of a maximum 1 Mbps method for specification and representation of policies, 
available bandwidth. If a new request for 300 Kbps is Since a PBNM architecture will generally be designed for 
accepted by policy server 18 at priority 7, the LPM can now 30 policy-based control over the use of a variety of physical 
remove the previously-accepted reservation at priority 2 to resources (e.g., network bandwidth) and logical resources 
make room for the new reservation. In addition, or (e.g., multicast channels), it is desirable for the method of 
alternatively, pohcy server 18 may include a hold-off timer policy specification to be independent of particular resource 
value in a response sent to policy client 22. The hold-off types. For purposes of illustration, the example PBNM 
timer value specifies a time interval over which the response 35 architecture shown in FIG. 1 is assumed to implement 
is valid so that the LPM may cache the results of the policies directed substantially to admission control (e.g., 
response for use over the interval. This mechanism avoids whether an end user or an application will be allowed access 
repeated queries to pohcy server 18 for the same or similar to a particular multicast channel) or resource reservation 
requests, thus reducing the processing load on both policy (e.g., who is permitted to reserve a given amount of band- 
server 18 and pohcy client 22. 40 width on a particular part of the network). In addition, the 

In such an implementation, the LPM keeps track of the illustrated architecture is assumed to support the specifica- 

admission state, hold-off timer, and priority associated with tion of policy rules involving the following aspects: privi- 

each accepted request. The LPM also communicates infor- leges based on an entity's identity, application of rules to 

mation pertinent to each request (e.g., the traffic specifica- groups of entities, restrictions based on time, restrictions 

tion for a bandwidth request, a user id, or source address) to 45 based on the number or amount of usage, and support for 

policy server 18 using an extensible object format. The types logical combinations of basic rules, 

of objects and their contents can be defined specific to a One possible approach to pohcy specification for the 

client type. For example, objects in an "RSVP" class can PBNM architecture shown in FIG. 1 involves the use of a 

encapsulate bandwidth reservation information, whereas tree-based representation of rules that uses first-order logic 

objects in a "Traffic" class can encapsulate requests for use 50 for combining basic elements. A general tree-based repre- 

of a particular user-priority. In addition, each request to sentation of resource usage/access policies is partially 

policy server 18 can be assigned a locally unique RIH shown in FIG. 3. The illustrated tree structure makes it 

(Request Identification Handle) so that responses can be possible to specify a plurality of policy modules 52, 54 for 

matched against requests when more than one request is one or more managed resources 50. For example, pohcy 

outstanding. It should be noted, however, that the present 55 module 52 and pohcy module 54 represent specific rules that 

invention is not limited by such implementation details. specify restrictions on accessing resource 50. In a typical 

Looking more closely at communications between policy implementation, there would be pohcy modules relating to 

server 18 and pohcy client 22, a suitable protocol for a plurality of managed resources. Moreover, a given pohcy 

exchanging policy information can be relatively simple, module can apply to only a single resource and/or the tree 

consisting mainly of four types of messages: RQ (Request 60 structure could be arranged such that a policy module 

Query, used to query policy server 18), RR (Request applies to a plurality of resources. In the example shown, 

Response, sent by pohcy server 18 in response to a query), policy modules 52 and 54 are logically "OR'ed" together to 

DQ (Delete Request, used by policy client 22 to delete state specify alternative rules that apply to resource 50 (i.e., only 

associated with a previously-accepted request), and UR one of the rules needs to be satisfied for the rule to apply). 

(Unsolicited Response, used by policy server 18 to modify 65 Moving further down the tree structure, policy module 52 

its decision or priority associated with a previously-accepted comprises a combination of pohcy categories 56, 58 that are 

request). For instance, pohcy chent 22 can use such a logically "AND'ed" together. Each pohcy category 56, 58 
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represents a distinct classification, such as user identity, The sample policy rule also has two policy templates 

source hosts, time ranges, and so on. Together, policy associated with it for ensuring that the foregoing policy 

categories 56, 58 form a single rule (i.e., policy module 52) conditions are met. First, a network management policy 

that applies to resource 50. Policy categories may also template will ge nerat e apolicyjhat allows Jo hn Doe to ma ke 

comprise exclusions by using, for example, a negation 5 a reservation for 100 Kbps of-b'andwiclth on each of the 

operator (e.g., NOT). routers onJhe„path between John Doe andThTsAF^e^ 

Moving still further down the tree structure, policy cat- preempting other^user ^elel^ions ''if"necessary. For 

egory 56 comprises a plurality of element groups 60, 62 that cxamp i c> such a tempkoTmight bef (T AIlow John Doe to 

are logically " OR 'ed" together. Finally, at the bottom level reserve irjrj ^ a traffic on rQUter _ x fof SAP lraffic/ , 

of the tre^t^ture, the leaves represent basic elements or whefc rQ fc ^ . opcc triggcr ^ actiyatcd ^ 

enuties 64, 66 identifying, for example, such details of . r . . ^cirz: iC rx j *u cafi 

.. ,~ i u !• i * j the list of routers in the path between John Doe and the SAP 

po hcv module 52 as a network number, particular usends, or .. -,V . - n j ^ -n 

host addresses. As can be seen, an element group constitutes servcL ^ V oh ^ ™ 11 be u^aU^ly^n Jhe. specific 

an OR'ed combination of a set of leaves (i.e., entities). T0Xli ^ betweejUghnDo^ano^Sj^^ and will only 

By way of further example, FIG. 4 illustrates a particular »EP»Y -to^eservations made Jor SAP traffic^ Similarly, a 

implementation of a tree structure such as that shown in FIG. * 5 system management:p6Ucyj^pja]ejMiU generatea policy 

3. Given the foregoing description, it can be seen that this that specifies toaUheJnvemory^ new 
sample tree structure implements the following policy: requests by users other than John Doe Jf the server. load is 

No more than 1 Mbps bandwidth can be used by members greater than 2.00./This policy will be installed on the SAP 

of user group QoSUsers during the work hours of seryejiatself. 

8am-noon or lpm-5pm 20 In the foregoing example, the trigger that causes the 

In accordance with embodiments of the present invention, policy rule to be evaluated is John Doe logging in or out at 

a PBNM architecture, such as that illustrated in FIG. 1, can any host on the network. More generally, it will be appre- 

advantageously be configured such that policies are ciated that appropriate policy rules are generated and 

synthesized, installed and removed in an automated fashion, installed/uninstalled based on rule templates as a result of a 

essentially on an as-needed basis. In general, to accomplish 25 trigger even occurring, for example, at a PDP or a PEP. 

this a set of policy rules applicable to one or more managed Moreover, any device (i.e., not just PDPs or PEPs) can 

network resources is implemented at a policy server. When readily be configured to support such triggers by relaying the 

a particular policy rule is satisfied, the policy server dynami- occurrence of a trigger event to a device configured to act on 

cally generates one or more policies and installs them at the trigger. 

appropriate policy decision points. Once the installed poli- 30 gy way G f further illustration, FIG. 6 provides a flow 

cies are no longer necessary or useful, they are removed diagram describing how the foregoing example policy rule 

from the PDPs. is processed. With further reference to the architecture 

Such an embodiment may be implemented, for example, shown in FIG. 1, assume that John Doe logs onto a host 

using a dynamic policy rule 70 such as that illustrated in computer (Step 100) that includes PDP logic. The PDP is 

FIG. 5. Dynamic policy rule 70 comprises a data structure 35 configured to recognize this as a trigger event, and transmits 

that includes a description 72, a set of conditions 74, and a a message to an associated policy server 18 detailing the 

set of policy templates 76. Description 72 is simply a eve nt. Policy server 18 then determines whether it has a 

human -readable textual description of the purpose or goal of policy rule corresponding to the trigger event (Step 110). If 

the dynamic policy rule 70, and is provided merely for S0) policy server 18 identifies all of the network resources 

administrative convenience. Conditions 74 are used to deter- 40 involved with the policy rule (Step 120). To obtain such 

mine whether dynamic policy rule 70 is triggered. Like the information, the policy rule can be configured with logic to 

tree structure discussed above with reference to FIGS. 3 and query the MIBs on network devices or to consult a store of 

4, conditions 74 may consist of a plurality of policy condi- network information, such as a directory server. 

tions combined with logical operators (e.g., AND, OR, i n t hi s example, policy server 18 will identify (1) the SAP 

NOT). 45 server and (2) all routers between the host computer and the 

Policy templates 76 are data structures used to dynami- SAP server. Policy server 18 then determines whether John 

cally generate policies for installation at a PDP upon satis- rj oc ^ logging in or logging out (Step 130) based on the 

faction of conditions 74. Each policy template 76 corre- information passed by the host computer. Here, since John 

sponds to a predefined policy, and may include variables or Doe is logging in, policy server 18 uses the policy templates 

"wildcards" that are filled in with information relating to, for 50 associated with the policy rule to generate appropriate 

example, satisfied conditions, the network resource sought policies for each of the involved network resources (Step 

to be accessed, the identity of the entity requesting access to 140), and deploys the policies to those network resources 

the network resource, and so on. Policy templates 76 can be (step 150). Had pohcy server 18 determined that the trigger 

configured on a per-rule basis. eve nt was John Doe logging out, policy server 18 would 

To illustrate the use of dynamic policy rules such as that 55 have caused the previously-deployed policies to be removed 

shown in FIG. 5, consider a policy rule directed to ensuring from each of the network resources (Step 160). 

that a particular user (i.e., John Doe) is always able to access [ n contrast to current practice in PBNM systems, embodi- 

an inventory database resident on an SAP server in a ments 0 f fa c present invention eliminate the need for all 

corporate intranet (i.e., an inter-enterprise server developed currently-specified policies to be installed and evaluated at 

by SAP AG). This sample policy rule has two conditions 60 cacn prj>p associated with a managed network resource, 

associated with it: Instead, it is possible to reduce the policies installed on a 

Condition 1: John Doe must be able to reserve at least 100 PDP to a working set of policies that are actually needed at 

Kbps of bandwidth between wherever he is on the a given time. Persons skilled in the art will readily recognize 

network and the database server. the benefits of such an approach, such as significantly 

Condition 2: The load on the database server must be kept 65 reducing the processing load on individual PDPs and PEPs. 

below a certain limit (Le., 2.00) whenever John Doe is For example, it is not necessary for a PDP to continually 

connected to the network. evaluate conditions for each and every established policy. 
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PEPs also need not evaluate as many conditions. For 
instance, if no policies are currently installed on the PEP 
which deal with a particular type of request, the PEP wiU not 
need to query a PDP whenever a request of that type occurs. 
Similarly, a PDP will not have to process a long list of 5 
policies to evaluate whether to allow such a request. Rather, 
the use of policy templates makes it possible to ensure that 
the policies installed on a PDP are much more specific than 
would otherwise be possible, since it is not necessary to try 
to accommodate a wide variety of different conditions 10 
through, for example, the use of wildcards. 

As noted above, policy rules are typically installed on a 
policy server in accordance with embodiments of the present 
invention. The conditions associated with a given policy rule 
may be evaluated periodically by the policy server, or may 15 
be evaluated in response to some trigger event, as in the 
foregoing example. Uiis latter approach has the advantage 
of leveraging current PBNM architectures wherein PDPs 
automatically evaluate policy conditions when a request is 
made for a managed resource. That is, the existing process- ^ 
ing could be modified such that the evaluation of policy 
conditions would alternatively, or additionally, trigger a 
policy server to evaluate any policy rules that contained 
those conditions. 

The foregoing is a detailed description of particular 25 
embodiments of the claimed invention; however, the 
claimed invention also embraces all alternatives, modifica- 
tions and variations that fall within the letter and spirit of the 
appended claims, as well as all equivalents of the claimed 
subject matter. For example, trigger processing can be 30 
installed on devices other than PDPs or PEPs, such as work 
stations. In accordance with another possible alternative, the 
infrastructure used for dynamic policy generation can be 
implemented physically separate from the basic PBNM 
architecture by, for example, providing separate policy rule 3S 
evaluation servers that interact with trigger devices and 
remotely configure PDPs. Similarly, a PBNM system could 
be configured such that a policy server communicates with 
a policy management device configured to generate policies, 
install policies on the policy server, and remove policies 40 
from the policy server. Persons skilled in the art will 
recognize that many other alternatives, modifications and 
variations are also possible. 

What is claimed: 

1. A computer-implemented method comprising: 45 
evaluating a condition relating to a network resource; 
generating instructions for managing access to the net- 
work resource in response to the evaluation; and 

transmitting the instructions for installation on a network 
device providing access to the network resource. 50 

2. The computer-implemented method of claim 1, 
wherein the instructions are generated from a template. 

3. The computer-implemented method of claim 2, 
wherein the instructions are customized using information 
relating to the evaluated condition. 55 

4. The computer-implemented method of claim 2, 
wherein the template is selected from a plurality of tem- 
plates based on information relating to the evaluated con- 
dition. 

5. The computer-implemented method of claim 1, further 60 
comprising removing the instructions from the network 
device after execution. 

6. The computer-implemented method of claim 1, 
wherein the condition is evaluated periodically. 

7. The computer-implemented method of claim 1, 65 
wherein the condition is evaluated in response to a prede- 
termined event. 
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8. The computer-implemented method of claim 7, 
wherein the predetermined event relates to an attempt to 
access the network resource. 

9. The computer-implemented method of claim 1, further 
comprising generating instructions for installation on each 
of a plurality of network devices providing access to the 
network resource. 

10. The computer- implemented method of claim 1, fur- 
ther comprising generating instructions for managing access 
to a plurality of network resources associated with the 
evaluated condition. 

U, A machine-readable medium having stored thereon a 
plurality of executable instructions to perform a method 
comprising: 

evaluating a condition relating to a network resource; 
generating a module for managing access to the network 

resource in response to the evaluation; and 
transmitting the module for installation on a network 

device providing access to the network resource. 

12. The storage medium of claim 11, wherein the set of 
instructions further comprises instructions for generating the 
module from a template. 

13. The storage medium of claim 12, wherein the set of 
instructions further comprises instructions for customizing 
the module using information relating to the evaluated 
condition. 

14. The storage medium of claim 12, wherein the set of 
instructions further comprises instructions for selecting the 
template from a plurality of templates based on information 
relating to the evaluated condition. 

15. The storage medium of claim 11, wherein the set of 
instructions further comprises instructions for removing the 
module from the network device after execution. 

16. The storage medium of claim 11, wherein the set of 
instructions further comprises instructions for evaluating the 
condition periodically. 

17. The storage medium of claim 11, wherein the set of 
instructions further comprises instructions for evaluating the 
condition in response to a predetermined event. 

18. The storage medium of claim 17, wherein the prede- 
termined event relates to an attempt to access the network 
resource. 

19. The storage medium of claim 11, wherein the set of 
instructions further comprises instructions for generating a 
plurality of modules and respectively installing them on a 
plurality of network devices providing access to the network 
resource. 

20. The storage medium of claim 11, wherein the set of 
instructions further comprises instructions for generating 
modules for managing access to a plurality of network 
resources associated with the evaluated condition. 

21. A policy -based network management system compris- 
ing: 

a policy enforcement point to selectively enable access to 
a network resource; 

a policy decision point in communication with the policy 
enforcement point, the policy decision point to autho- 
rize access to the network resource through the policy 
enforcement point in accordance with an established 
policy; and 

a policy server in communication with the policy decision 
point, the policy server to maintain a template for 
dynamically establishing a policy concerning access to 
the network resource and communicating the estab- 
lished policy for installation on the policy decision 
point. 
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22. The policy-based network management system of 
claim 21, wherein the policy server generates a policy in 
response to satisfaction of a predetermined condition. 

23. The policy-based network management system of 
claim 22, wherein the policy server evaluates the predeter- 
mined condition periodically. 

24. The policy-based network management system of 
claim 22, wherein the policy server evaluates the predeter- 
mined condition upon detection of a network event. 

25. A policy-based network management system compris- 
ing: 

a policy enforcement point to selectively enable access to 
a network resource; 

a policy decision point in communication with the policy 
enforcement point, the policy decision point to autho- 
rize access to the network resource through the policy 
enforcement point in accordance with an established 
policy; and 

a policy server in communication with the policy decision 
point, the policy server to maintain a template for 
dynamically establishing a policy concerning access to 
the network resource and communicating the estab- 
lished policy to the policy decision point, 

the established policy comprising a set of instructions 
installed on the policy decision point. 

26. The policy-based network management system of 
claim 25, wherein the policy server generates a policy in 
response to satisfaction of a predetermined condition. 

27. The policy-based network management system of 
claim 26, wherein the policy server evaluates the predeter- 
mined condition periodically. 

28. The policy-based network management system of 
claim 26, wherein the policy server evaluates the predeter- 
mined condition upon detection of a network event. 

29. A policy -based network management system compris- 
ing: 

a policy enforcement point to selectively enable access to 
a network resource; 

a policy decision point in communication with the policy 
enforcement point, the policy decision point to autho- 
rize access to the network resource through the policy 
enforcement point in accordance with an established 
policy; and 

a policy server in communication with the policy decision 
point, the policy server to maintain a template for 
dynamically establishing a policy concerning access to 
the network resource and communicating the estab- 
lished policy to the policy decision point, 

the established policy being removed from the policy 
decision point upon occurrence of a predetermined 
event. 

30. The policy-based network management system of 
claim 29, wherein the policy server generates a policy in 
response to satisfaction of a predetermined condition. 

31. The policy-based network management system of 
claim 30, wherein the policy server evaluates the predeter- 
mined condition periodically. 

32. The policy-based network management system of 
claim 30, wherein the policy server evaluates the predeter- 
mined condition upon detection of a network event. 

33. A policy-based network management system compris- 
ing: 

a policy enforcement point to selectively enable access to 

a network resource; 
a policy decision point in communication with the policy 

enforcement point, the policy decision point to autho- 
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rize access to the network resource through the policy 
enforcement point in accordance with an established 
policy; 

a policy server in communication with the policy decision 
point, the policy server to maintain a template for 
dynamically establishing a policy concerning access to 
the network resource and communicating the estab- 
lished policy to the policy decision point; and 

a plurality of policy decision points coupled to the policy 
server, each of the plurality of policy decision points to 
authorize access to a different network resource. 

34. The policy-based network management system of 
claim 33, wherein the policy server generates a policy in 
response to satisfaction of a predetermined condition. 

35. The policy-based network management system of 
claim 34, wherein the policy server evaluates the predeter- 
mined condition periodically. 

36. The policy-based network management system of 
claim 34, wherein the policy server evaluates the predeter- 
mined condition upon detection of a network event. 

37. A policy -based network management system compris- 
ing: 

a policy enforcement point to selectively enable access to 
a network resource; 

a policy decision point in communication with the policy 
enforcement point, the policy decision point to autho- 
rize access to the network resource through the policy 
enforcement point in accordance with an established 
policy; 

a policy server in communication with the policy decision 
point, the policy server to maintain a template for 
dynamically establishing a policy concerning access to 
the network resource and communicating the estab- 
lished policy to the policy decision point; and 

a plurality of policy enforcement points coupled to the 
policy decision point, each of the plurality of policy 
enforcement points to selectively enable access to the 
network resource. 

38. The policy-based network management system of 
claim 37, wherein the policy server generates a policy in 
response to satisfaction of a predetermined condition. 

39. The policy-based network management system of 
claim 38, wherein the policy server evaluates the predeter- 
mined condition periodically. 

40. The policy-based network management system of 
claim 38, wherein the policy server evaluates the predeter- 
mined condition upon detection of a network event. 

41. A policy-based network management system compris- 
ing: 

a policy enforcement point to selectively enable access to 
a network resource; 

a policy decision point in communication with the policy 
enforcement point, the policy decision point to autho- 
rize access to the network resource through the policy 
enforcement point in accordance with an established 
policy; and 

a policy server in communication with the policy decision 
point, the policy server to maintain a template for 
dynamically establishing a policy concerning access to 
the network resource and communicating the estab- 
lished policy to the policy decision point, and the policy 
server to maintain a plurality of templates for dynami- 
cally establishing a policy concerning access to each of 
a plurality of network resources. 

42. The policy -based network management system of 
claim 41, wherein the policy server generates a policy in 
response to satisfaction of a predetermined condition. 
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43. The policy-based network management system of 
claim 42, wherein the policy server evaluates the predeter- 
mined condition periodically. 

44. The policy-based network management system of 
claim 42, wherein the policy server evaluates the predeter- 
mined condition upon detection of a network event. 

45. A policy-based network management system compris- 
ing: 

a policy enforcement point to selectively enable access to 
a network resource; 

a policy decision point in communication with the policy 
enforcement point, the policy decision point to autho- 
rize access to the network resource through the policy 
enforcement point in accordance with an established 
policy; 

a policy server in communication with the policy decision 
point, the policy server to maintain a template for 
dynamically establishing a policy concerning access to 
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the network resource and communicating the estab- 
lished policy to the policy decision point, and the policy 
server being in communication with a policy manage- 
ment device, the policy management device to perform 
at least one of the functions of generating policies, 
installing policies on the policy server, and removing 
policies from the policy server. 

46. The policy -based network management system of 
claim 45, wherein the policy server generates a policy in 

1 response to satisfaction of a predetermined condition. 

47. The policy -based network management system of 
claim 46, wherein the policy server evaluates the predeter- 
mined condition periodically. 

. 48. The policy -based network management system of 
claim 46, wherein the policy server evaluates the predeter- 
mined condition upon detection of a network event. 
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